Relational database systems store tables of data which are typically linked together by relationships that simplify the storage of data and make queries of the data more efficient. Structured Query Language (SQL) is a standardized language for creating and operating on relational databases.
Many relational database systems have the capability to save a compiled execution plan for a SQL query and to re-use the saved plan for subsequent execution of the same query. Storing the compiled execution plan saves the CPU cost of having to repeatedly parse and optimize frequently executed queries. This feature can be used to ensure consistent query performance. Relational database system typically includes an optimizer that plans the execution of SQL queries. The optimizer's chosen plan for a given query can change as data characteristics change or the optimizer's software itself changes. In turn, varying the execution plan can increase the likelihood of an inefficient plan being chosen and resulting performance regression. Consistently using the same stored execution plan minimizes the risk associated with varying plans by locking in the desired execution plan.
Over time however, stored execution plans eventually becomes sub-optimal (often termed stale) as system characteristics change. The most common reasons for a plan becoming sub-optimal are:                new indexes for updated statistics become available;        a newer version of the query optimizer software is installed which contains new optimization techniques; and        the computer hardware on which the query is running is changed.        
It is also known for an optimizer to fail to choose the best available plan, sometimes as a result of a defect in the optimizer's code or sometimes due to limitations of the technology employed in the optimizer.
Sophisticated query optimizer's take into account how the specification of the system's CPU, disks, network interconnect, and data cache size when estimating cost or alternative plans. Typically a stored set of configurable “cost parameters” in the data dictionary will be stored in the data dictionary that represent either; the cost of performing well defined low level operations (for example, cost to read one block from a disk), or the configured size of a resource (for example data cache size). These cost parameters are used by the optimizer's formulae to estimate the total cost for varies execution methods (for example file scan, sort, nested loop, join etc). When a system's hardware is changed the optimizer's cost parameters are also changed accordingly. Changes to the hardware configuration can produce a change in the actual resource cost, which may or may not be reflected properly in optimizer's estimation of the resources necessary to execute a particular query.
To allow refreshing of sub-optimal plans, most vendors provide a “with recompile” SQL syntax option, that will manually force the query to be recompile upon execution. More advanced systems may even support automatic recompiles based on built in rules that detect when plans become sub-optimal.
A serious danger in recompiling stored execution plans is that there is no guarantee that the performance of the new plan is better than the current stored one and it can be worse, in which case it may not be possible to revert to the old execution plan.